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1 .  Introduction 

Since  the  last  report  the  development  of  CRANES  has  proceeded  satisfactorily. 

Section  2  describes  this  work  and  no  further  comment  is  offered  here. 

»  ' 

Regarding  the  BID/NO  BID  domain  we  have  made  good  progress  with  the  other 
contractor  mentioned  in  our  last  report  namely  IDC  Ltd  of  Stratford  on  Avon. 

We  are  dealing  with  Mr  Ivor  Davies,  the  Deputy  Chairman,  and  his  reactions  have 
been  favourable . 

We  have  concluded  that,  on  account  of  the  paucity  of  information  on  real 
world  cases  we  should  try  a  different  approach  in  the  general  exploration  of 
knowledge  acquisition  methods.  In  particular  we  shall  attempt  to  produce  a 
system  to  advise  project  managers  on  items  such  as  the  scheduling  technique, 
the  level  of  sophistication  and  detail  and  on  methods  of  training  and  communi¬ 
cation.  We  plan  to  use  this  as  a  vehicle  to  explore  alternative  methods. 

We  have  continued  our  work  on  rule  induction  but,  as  previously  reported, 
we  are  giving  this  work  a  low  priority.  We  have  had  interesting  discussions 
with  Rense  Lange  of  CERL  and  had  some  correspondence  with  him  regarding  his 
program  STAT.  However  the  details  he  has  sent  us  are  at  present  incomplete . 

We  have  written  to  Frank  Kearney  to  suggest  that  Rense  Lange  should  visit  us  to 
try  out  his  program  on  data  we  can  supply.  No  decision  on  this  is  yet  available 
but  we  remain  convinced  that  a  short  visit,  say  of  2  or  3  weeks,  would  be  bene¬ 
ficial  for  the  project. 
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The  remainder  of  Jhis  report  is  presented  under  the  following  headings  . 
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SECTION  2  CRANES 
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!  Work  on  the  cranage  domain  has  continued  with  a  total  of  7  knowledge 

elicitation  meetings  completed  and  a  prototype  system  coded  for  the  SAVOIR 
shell  now  in  operation.  . 

The  knowledge  elicitation  sessions  have  brought  to  light  a  number  of 
interesting  findings  including  the  following: 

•  In  the  early  stages  the  experts'  description  of  their  method  of  working  when 
choosing  cranes  appeared  to  change  markedly  between  one  meeting  and  the  next. 

•  Each  expert  has  his  own  approach  to  the  important  hook  time  calculation  (an 
estimate  of  the  number  of  cranes  required  to  perform  the  necessary  duties) . 
Experts  tended  to  talk  in  general  terms  about  this  calculation  but  were 
reluctant  to  reveal  the  actual  figures  they  themselves  assumed.  This  may  in 
part  have  been  due  to  a  reluctance  to  be  "shown  up"  in  front  of  colleagues. 

•  The  two  most  senior  experts  appear  most  sympathetic  to  the  objectives  of  the 
work  and  hence  have  provided  the  most  useful  knowledge. 

•  When  the  first  prototype  system  was  demonstrated  to  the  most  senior  expert 
it  became  clear  that  his  expectation  had  been  of  an  automatic  system  capable 
of  underts tending  a  co-ordinated  model  of  a  building  rather  than  an  advice 
system.  This  was  suprising  in  view  of  earlier  discussions  we  had  had  about 
the  purpose  of  the  graphic  displays  we  are  developing. 

•  Experts  tend  to  dismiss  complex  areas  of  knowledge  as  too  difficult  to 
formalize  and  it  is  often  difficult  to  elicit  knowledge  about  such  areas. 

The  prototype  system  is  being  developed  as  a  series  of  modules  to  enable 
the  user  some  freedom  in  the  order  of  approach  to  his  particular  problem. 

Modules  in  operation  so  far  are  as  follows: 

1.  Preliminary  strategy  module.  This  is  aimed  at  the  novice  user  to  advise 
whether  to  consider  the  superstructure  or  basement  first  and  to  indicate  which 
type  of  crane  (i.e.  tower,  crawler,  mobile)  he  should  consider  first. 

2.  Hook  time  calculation.  An  essential  calculation  to  determine  the  minimum 
of  crane  hooks  required  to  complete  the  structure  within  the  contract  period. 

The  module  will  be  required  severed  times  -  for  the  superstructure,  for  the 
basement,  and  later  to  check  that  each  individual  crane  can  do  what  is  asked  of  it. 
Considerable  knowledge  acquisition  effort  has  been  focussed  on  this^topic  and  the 
resulting  system  module  embodies  much  specialist  expertise. 

3.  Graphics  module.  Besides  having  sufficient  hook s  to  perform  the  required 
creme  duties  within  the  construction  period  the  planning  engineer  must  also 
position  cranes  suitably  to  cover  the  whole  structure.  The  graphics  module  enables 
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him  to  define  and  adjust  the  coverage  of  tower  cranes  on  a  graphic  display. 

The  system  then  checks  that  cranes  capable  of  lifting  the  necessary  loads  at 
the  required  radii  are  available  using  a  data  base.  Development  of  software 
to  enable  graphics  routines  to  be  called  from  the  SAVOIR  shell  has  taken  con¬ 
siderable  effort.  However  our  discussions  with  the  domain  experts  led  us  to 
conclude  that  this  facility  was  essential  to  any  real  world  system. 

For  the  immediate  future  it  is  our  intention  to  concentrate  on  tower  cranes 
and  to  attempt  to  expand  the  system  into  the  following  areas: 


choice  of  jib  type 

choice  of  foundation  for  the  creme 

methods  of  crane  erection  and  dismantling 

advice  on  when  cranage  requirements  might  be  reduced  by,  say,  pumpiio 
or  working  overtime 

when  to  bring  in  a  large  mobile  creme  for  heavy  lifts 


Accession  For 

NTIS  GRAfcl 
DTIC  TAB 
Unannounced 
Jittt  if  1  catlap 


Distribution/ _ 

Availability  Codes 
[Avail  and/or 
Dist  Special 


cf 
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SECTION  3  BID/NO  BID 

3.1  Introduction 

The  bid/no  bid  system  has  been  developed  in  conjunction  with  IDC  Consultants, 
a  firm  of  design/construct  contractors .The  system  is  designed  to  advise  the  user 
in  deciding  whether  or  not  to  bid  in  response  to  a  new  enquiry.  Intially,  the 
system  was  intended  to  be  developed  using  SAVOIR.  However,  after  consultations 
with  the  Deputy  Chairman  and  his  colleagues,  the  prototype  system  has  been 
developed  as  a  forward- chaining  interpreter.  The  knowledge  base  is,  however, 
separate  from  the  inference  mechanism,  enabling  it  to  be  used  by  other  companies. 

3.2  System  description 


BID/NO  BID  operates  with  a  knowledge  base  containing  some  120 "checklist" 

i 

items  and  an  interpreter  which  calculates  the  bid  "scores"  from  the  values 
assigned  by  the  user  to  each  checklist  item.  The  checklist  items  are  weighted 
according  to  the  significance  ascribed  to  them  by  IDC's  "experts".  The  system 
also  contains  a  built-in  editor  which  can  be  used  to  delete  items;  add  items; 
change  the  wording  of  items;  resequence  the  order  of  presentation  of  the  checklist, 
or  change  the  weights  or  type  of  each  item.  Item  "type"  refers  to  the  way  in 
which  the  item  is  scored  (-5  to  +5;  Yes  or  No;  0  to  lOO)  .  The  checklist  is 
structured  into  a  series  of  modules  as  follows: 

•  preliminary  questions:  this  module  contains  factors  identified  by  IDC  as 
factors  which,  may,  depending  on  the  answers,  unequivocally  mean  a  straight-forward 
decision  to  bid  or  not  to  bid.  The  remaining  modules,  serve  to  clarify  a  situation. 

where  the  position  is  uncertain 

•  client- factors:  this  module  contains  factors  which  evaluate  client  charactersitics 
such  as  financial  soundness 

•  project  factors:  this  module  evaluates  details  of  the  proposed  project 

•  bid  factors:  this  module  evaluates  the  bidding  situation  in  terms  of  factors 
like  number  of  competitors  involved 

•  resource  factors:  this  module  evaluates  IDC's  capacity  to  "cope"  with  the 
project's  resource  requirements. 

3.3  Knowledge  acquisition 

The  knowledge  base  was  developed  using  two  main  techniques:  interviews 
and  documentation  analysis.  Initial  knowledge  elicitation  sessions <4*ere  carried 
out  in  the  form  of  "unstructured"  interviews.  A  subsequent  session  was  carried 
out  using  a  structured  inteview  approach.  The  data  obtained  from  the  intial 
interviews  was  analysed  and  classified  into  categories.  In  particular,  contra¬ 
dictions  in  the  data  -  were  identified  and  resolved. 
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This  "resolution  of  contradiction”  approach  proved  to  be  a  particularly 
fruitful  means  of  expanding  the  knowledge  base. 

The  base  was  subsequently  expanded  by  incorporating  a  number  of 
factors  drawn  from  a  previous  project  carried  out  by  XDC  for  training 
purposes  on  bid  strategies. 


3.4  Further  development 

• 

XDC  are  currently  using  the  prototype  system  as  a  training  aid.  A 
procedure  has  been  agreed  whereby  one  of  the  experts  involved  in  the 
elicitation  sessions  will  monitor  the  use  of  the  system  and  record  responses 
to  it.  Xn  this  sense,  the  current  phase  of  the  project  constitutes  both 
verification  and  elecitation,  since  it  is  envisaged  that  additional  data 

will  be  generated  in  the  ensuing  monitoring  phase.  Decisions  on  further 

1 

developments  will  be  based  on  the  findings. 
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SECTION  4  EXTRACTING  SIGNIFICANT  INFORMATION  ON  KNOWLEDGE  ACQUISITION 


4.1  Introduction 

We  set  out  initially  to  investigate  the  area  of  knowledge  acquisition 
because  it  was  generally  accepted  in  "expert  system"  circles  that  knowledge 
acquisition  was  difficult,  badly  co-ordinated,  sparsely-researched- 
and  of  crucial  importance  to  the  development  of  careful  and  efficient  intelligent 
know ledge- based  systems. 

Our  experiences,  after  almost  a  year  of  that  investigation,  has  largely 
confirmed  this  view.  Indeed,  the  history  of  the  investigation,  and  the  direction 
in  which  it  has  been  led,  has  been  shaped  to  a  large  extent  by  the  difficulties 
the  project  team  has  experienced  in  firstly  obtaining  information  on  knowledge 
acquisition,  and,  secondly,  in  imposing  a  coherent  structure  on  the  information 

obtained. 

1 

In  the  early  stages,  it  was  envisaged  that  our  existing  awareness  of  expert 
system  projects  in  construction-related  fields,  or  in  applications  within  our 
sphere  of  contacts,  would  generate  sufficient  diversity  of  case  material  to 
enable  us  to  develop  typologies  of  knowledge  acquisition  and  to  produce  definitive 
recommendations  to  support  the  development  of  a  useful,  practical  methodology. 

A  number  of  factors  made  the  undertakings  difficult;  not  least  the  growing 

evidence  that  many  expert  system  applications  were  based  on  knowledge  acquisition 

processes  which  had  proceeded  ad  hoc  without  the  support  of  a  pre-determined, 

systematic  methodology.  Other  problems  -  notably  the  lack  of  detailed  and  up-to- 

date  information  on  knowledge  acquisition  aspects  of  expert  systems  (typified  by 

the  d'Agapeyeff  and  OVUM  reports)  ;  and  the  tendency  for  developers  of  expert 

systems  to  play  their  cards  close  to  the  chest  -  has  forced  the  research  team  to 

/  « 

adopt  a  diversified  approach  to  the  investigation  of  knowledge  acquisition. 

This  approach  is  focussed  on  three  main  themes: 

i)  Practical  e^qperience  in  the  development  of  working  expert  systems 

ii)  Detailed  analysis  of  case  study  material 

iii)  Evaluation,  under  experimental  conditions,  of  comparative 
knowledge  acquisition  methods 


4.2  Development  of  expert  systems 

As  noted  above  we  axe  already  working  on  CRANES  and  BID/NO  BID.  We  are 
just  starting  on  the  development  of  PROJECT  MANAGEMENT  which  will  form  the 


vehicle  for  the  comparative  study  described  in  section  4.4  below. 
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4.3  Case  studies 

To  augment  our  access  to  case  study  material  we  are  conducting  a  survey 
of  industrial  companies .  The  questionnaire  which  forms  the  basis  of  this 
survey  is  designed  to  elicit  data  on 

•  past,  present  and  future  expert  system  applications. 

•  knowledge  acquisition  techniques  employed  and  problems  encountered. 

4.4  Comparative  knowledge  acquisition  methods 


We  have  started  to  explore  the  following  methods  of  knowledge  acquisition 
and  plan  to  apply  each  to  one  module  within  the  general  domain  of  PROJECT 
MANAGEMENT. 

»  Use  of  questionnaire  survey 

•  Fast  prototyping 

•  Machine  induction 

•  Evolutionary  development 

Each  is  now  amplified 

Survey  Questionnaires  have  been  despatched  to  a  structured  sample  of  project 
managers  and  planners  obtained  partly  by  negotiation  with  the  Association  of 
Project  Managers  and  partly  from  the  Association  of  Consulting  Engineers. 


Fast  prototyping  This  is  an  expression  that  is  being  used  in  KBS  circles. 

It  refers  to  the  process  by  which  a  start  is  made  with  a  relatively  limited 

system  which  is  then  augumented  by  knowledge  acquired  from  domain  experts.  The 

principle  is  that,  the  existence  of  a  meaningful  system  prompts  the  experts  to 

contribute  from  their  experience. 

<  < 

Machine  induction  This  needs  little  amplification.  Section  5  reports  on  our 
experience  to  date. 

Evolutionary  development  The  evolutionary  method  involves  developing  the  expert 
system  from  "original"  data  extracts  using  a  number  of  different  interview 
techniques.  These  techniques  include: 

"unstructured"  interviews,  or  "brainstorming"  sessions 
•focussed"  interviews  based  on  pre-determined  questions 

structured  attitude-testing  inventories  including  multi-dimensioned  scaling 
and  repertory  grids 

■introspection"  involving  simulating  problems  with  the  expert 

She  research  design  adopted  in  the  "slow  prototyping"  approach  is  based  on 
the  "Latin  Squares"  method.  This  involves  4  experts  using  each  interview  type 
consecutively  (i.e.  Expert  1  starts  with  type  A;  Expert  2  with  type  B  and  so  on) 
in  order  to  reduce  the  effect  of  "personality"  and  "learning  curve"  factors 


Xy, 


M 

» 


on  the  outcomes.  During  the  interview  sessions,  responses  are  monitored  and 
evaluated  by  the  knowledge  engineer  on  the  basis  of  factors  such  as  volume  of 
data  extracted;  problems  encountered;  elapsed  time  and  "depth"  of  knowledge 
elicited. 

By  modules  within  project  management  we  mean  the  sets  of  goals  which 
reflect  the  expertize.  For  example  one  set  may  represent  alternative 
techniques,  another  set  the  choice  of  computer  program.  Several  more  modules 
would  be  necessary  to  represent  the  whole  domain  and  it  is  perhaps  worth  noting 
that  we  are  in  liaison  with  the  PARC  community  club  set  up  by  the  Department  of 
Trade  and  Industry. 


1 


SECTION  5  RULE  INDUCTION 


i 


5 . 1  Background 


As  described  in  an  earlier  Interim  Report  (Interim  Report  2  March  1986) 
our  evaluation  of  Expert-Ease  by  developing  a  sub-section  of  the  BREDAMP 
expert  system  raw  data  by  machine  induction  has  been  largely  negative .  Our 
main  conclusions  were  as  follows: 

Expert-Ease  works  best  on  hierachical,  deterministic  knowledge- trees  in  which 
outcomes  are  arrived  at  by  "single"  rather  than  multiple,  paths.  Expert-Ease 
inposes  its  own  algorithmic  logic  on  a  rule  base,  which  in  many  instances  is 
inconsistent  with  the  real  world  logic  perceived  by  the  expert. 

Expert-Ease  cannot  adequately  handle  uncertainty. 

The  program  "edits"  the  knowledge  base  input  according  to  its  own  induction 
process.,  and  there  is  very  little  user  control  available  over  this  process . 

However,  despite  these  disappointing  findings  we  had  received  good  reports  on 
Expert-Ease  from  an  international  oil  company.  In  their  case  the  experts  them¬ 
selves  use  the  program.  We  therefore  decided  to  undertake  a  further  evaluation 
using  the  BREDAMP  domain  expert. 

5.2  Procedure  adopted 

The  procedure  adopted  was  as  follows: 

i)  the  ceiling-under-floor  segment  of  BREDAMP  was  selected  for  the  evaluation. 

ii)  the  Expert  and  a  "knowledge  Engineer"  familiar  with  Expert-Ease  worked 
together  to  build  a  rule  base  for  the  Ceiling-under- floor  segment  directly 
into  the  computer. 

iii)  there  was  no  initial  "paper  model"  constructed.  The  sequence  of  operations 
worked  as  follows:'  ' 

Expert  decides  on  the  attributes  to  be  input. 

Knowledge  Engineer  keys  in  the  attributes  directly  into  Expert-Ease. 

Expert  identifies  suitable  examples  of  causes  of  Pipe  Leakage  in  a  ceiling 
under  floor. 

Knowledge  Engineer  inputs  examples  directly  into  Expert-Ease. 

Expert-Ease  induces  a  rule  consistent  with  Expert-defined  attributes  and 
examples . 
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5.3  Characteristics  of  rule  base  developed 

The  attributes  input  by  the  expert  showed  some  variation  from  those  used 

in  BREDAMP,  although  the  variations  were  largely  a  matter  of  emphasis  rather 

than  "new"  variables.  As  the  initial  evaluation  of  Expert-Ease  demonstrated, 

the  program  needs  to  generate  a  fairly  strictly  defined  hierarchical  tree. 

Thus,  it  finds  it  difficult  to  handle  situations  within  BREDAMP  which  contain 

mutually  exclusive  conditions  -  such  as  the  presence  of  a  drain  v.  a  rising  main. 

The  expert  attempted  to  overcome  these  problems  by  introducing  sub-bases  within 

the  overall  knowledge  tree  in  Expert-Ease . 

The  procedure  adopted  produced  the  following  set  of  steps : 

Establish  whether  there  is  a  stain 

If  stain  present,  identify  if  water  is  dripping 

If  yes,  establish  whether  the  floor  above  is  wet 

If  wet  continue 

IT  not  wet,  chain  to  sub- tree 

Establish  if  pipe  present 

If  No  chain  to  sub- tree 

If  yes,  establish  if  pipe  is  visible 

If  not  visible,  chain  to  sub- tree 

If  visible,  establish  type  of  pipe 

If  drain,  chain  to  sub- tree 

If  not  drain,  establish  if  pipe  is  wet 

If  sometimes  wet,  chain  to  sub- tree 

If  wet  continuously,  establish  type  of  wetness 

Then  probability  of  pipe  leak  is  established 

The  development  of  the  knowledge  base  in  this  type  of  modular  form  for  pipe 
leakage  was  aimed  at  eliminating  the  problems  encountered  in  the  initial  evalu¬ 
ation  of  Expert-Ease,  where  the  unitary  model  initially  developed  produced 
inconsistent  results . 

In  this  exercise  ;the  expert  developed  28  examples  in  order  to  conply  with 
the  operation  of  Expert  Ease.  This  is  considerably  more  than  the  number  developed 
originally  by  interview  techniques  and  suggests  that  machine  induction  may  have 
the  effect  of  expanding  the  knowledge  base. 

However,  the  rule  base  generated  using  the  attributes  and  examples  identified 
by  the  expert  was  inconsistent  with  the  expert's  cognitive  model.  As  in  the 
initial  evaluation  using  coding  from  BREDAMP,  the  rule  base  generated  was  illogical, 
mis-sequenced  and  omitted  a  number  of  critical  attributes. 

5.4  Observations 

Employing  the  expert  to  input  data  directly  into  the  program  elicited  a 
number  of  significant  departures  in  the  type  of  knowledge  elicited^compared  with 
the  data  elicited  in  the  original  BREDAMP  development  using  interviews  with 
subsequent  coding  for  SAVOIR.  These  are  now  listed. 
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•  The  expert  found  that  the hierarchical  structure  of  the  program  forced 
him  to  consider  hypothetical  "cases"  of  pipe  leakage  which  he  might  not 
otherwise  have  communicated  during  a  "conventional"  knowledge  elicitation 
process. 

•  These  cases  were  derived  from  the  expert's  interpretation  of  possible 
permutations  suggested  by  the  attributes  and  values  he  had  intially  input 
into  the  program,  and  from  "prompts"  (i.e.  nulls  and  clashes)  displayed  by 
Expert-Ease  after  rules  derived  from  the  data  had  been  produced. 

•  The  expert  considered  the  program  to  be  a  useful  elicitation  tool  as  a 
prompt  to  induce  knowledge  not  immediately  contained  within  the  expert's 
day-to-day  "portfolio"  of  expertise.  He  also  perceived  it  as  a  method  of 
verifying  existing  knowledge  and  a  means  of  forcing  him  to  outline  "deep 
knowledge"  representations  of  cases  normally  expressed  through  "shallow" 
representations . 

•  The  expert  considered  the  rules  induced  by  Expert-Ease  to  be  very  remote 
from  what  could  be  considered  to  be  a  realistic  knowledge  tree  for  the 
investigation  of  causes  of  damp  penetration  through  pipe  leakage.  Thus, 
the  expert  considered  the  prescriptive  element  of  the  program  (its  capacity 
to  act  as  an  interrogative  expert  system)  to  be  of  little  value. 

5.5  Conclusions 

The  evaluation  exercise  with  the  expert  confirmed  initial  impressions 
that  Expert-Ease  is  of  little  value  as  a  tool  to  develop  working  knowledge- 
based  systems  capable  of  interrogation  and  consultation.  However,  the  results 
of  the  evaluation  suggested  that  machine  induction  could  play  a  positive  role 
in  "second  stage"  elicitation.  Thus,  initial  domain  parameters  might  be 
established  through  conventional  means  (via  interviews,  content  analysis, 
observation,  task  analysis  etc)  and  Expert-Ease  used  to  fine-tune  these  initial 
parameters,  to  identify  "gaps"  in  the  knowledge  base,  to  verify  the  existing 
knowledge  and  to  generate  hypothetical  case  material  as  a  basis  for  further 
exploration  and  elicitation. 


6 .  Future  work 


The  foregoing  sections  on  CRANES,  BID/NO  BID,  and  knowledge 
acquisition  methods  each  include  statements  of  our  future  plans.  We  shall 
continue  to  give  low  priority  to  rule-induction  but  hope  that  it  may 
eventually  make  a  contribution  to  our  comparative  study  of  available  methods. 

We  have  deliberately  set  out  in  this  report  the  several  initiatives  we 
are  taking.  The  research  tedm  is  meeting  at  regular  intervals  to  exchange 
information  and  to  monitor  progress  and  thus  to  maintain  a  cohesive  line  of 
thought  about  the  project  as  a  whole.  We  are  giving  careful  consideration 
to  the  way  in  which  our  eventual  findings  can  be  encapsulated  in  a  structured 
framework. 
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